User Guide for Delay/Disruption Tolerant Networking Bundle Protocol Node (BPNode) v7.0

This BPNode v7.0 User Guide provides its users with general understanding of node functions. It covers node installation, configuration, and operations. The guide is intentionally generic to enable customization.

This software is available as an open source distribution, released under the Apache 2.0 license. The open-source license enables the industry adoption of BPNode. Outside of major releases, updates to the open repositories are limited to bug fixes and minor enhancements to these components.

This guide is developed and maintained by the DTN Project at NASA Goddard Space Flight Center. The document has been reviewed and approved by the team members as listed on the signature page. After initial approval, the document will be treated as a controlled document, placed under configuration management. Changes are listed in the document [Change History] log.

The development team also offers training, support, and subject matter expertise to government and industry users, and can provide custom development and integration services for flight projects. A support agreement may be required for certain engagements. To contact the team, email gsfc-dtn@nasa.onmicrosoft.com. Additional information is available on the DTN website: https://www.nasa.gov/communicating-with-missions/delay-disruption-tolerant-networking/.

The guide assumes that node operators are already familiar with BP and DTN, as well as with cFS Framework and how it integrates with COSMOS - the chosen telemetry and command system for interfacing with BPNode.

The BPNode application has been built and tested on Ubuntu 20.04.6 Long-Term Support.

cFS is a generic flight software architecture framework used on NASA spacecraft and cubesats. The cFS Framework is a core subset of cFS that offers an extensive ecosystem of applications and tools. The Figure 1, “Framework Structure” figure below demonstrates the external cFS and Core Flight Executive (cFE) framework structure. BPNode interacts with these elements to receive and distribute data for DTN service:

BPNode and BPLib are complementary components that run on top of the framework:

Together they provide a shared library and support BP and related functions.

BPNode contains the following subsystems, modules, and components:

For both BPNode and BPLib, the following dependencies are required:

On Ubuntu 20.04.6, install the necessary packages with:

BPLib relies on CBOR to handle the serialization and deserialization of data structures transmitted over the protocol. BPLib uses version 1.5.1 of QCBOR for CBOR data encoding and decoding.

Follow these steps to install QCBOR:

BPLib can be built as a standalone executable called bpcat, suitable for a ground relay node or as a demo of bplib’s features without the full CS architecture. This standalone build still depends on the OSAL library.

Build/run instructions for bpcat:

In the default bpcat configurations, a single contact is started that listens on 0.0.0.0:4501 and forwards bundles with the EID ipn:200.64 to 127.0.0.1:4551. To change these configurations, modify the ContactsTbl in bplib/app/src/bpcat_nc.c and rebuild bplib.

On startup, the BPNode main task will initialize itself, the BPLib library data, and any child tasks. On first initialization, the node creates a SQLite database named bplib-storage.db in the same directory as the executable (typically build/exe/cpu1/) along with temporary files associated with it. On subsequent initializations BPLib reads from it and reports the total number of bundles stored (see the Node MIB Reports telemetry packet as described in Chapter 6, Directives, Telemetry, Tables, and Events).

The node’s Endpoint Identifier (EID) is established during initialization by reading from the node MIB configuration table. This table contains an "instance EID" field that provides the base EID value used as the node’s primary identity. Channels use this EID for bundles originating on local applications, modifying the service number to match the corresponding value from the channel configuration table.

The counts of tasks are determined by the following BPNode or BPLib macros:

BPNode manages channel applications by separating configuration from activation, allowing for complete lifecycle control from setup through teardown. When an application needs to be integrated into the network, it must first be added to make its configuration available, then explicitly started to begin data flow. Applications can later be stopped to halt data processing or completely removed, which flushes any remaining data from both the egress queue and the cFE software bus pipe. These application lifecycle operations are controlled through the following directives:

Once active, applications participate in BP communication through two primary data flows:

This architecture allows BPNode to serve as a bridge between local cFS applications and the broader BP network, handling the translation between application-specific data formats and standardized bundle protocols.

BPNode manages network connections through contacts using a comprehensive lifecycle process similar to application management, allowing for complete control from initial setup through final teardown. Contacts represent network connections to other BP nodes and must be configured before they can actively participate in bundle routing. Like applications, contacts can be stopped to halt bundle traffic or completely torn down, which flushes any remaining bundles from the egress queue into storage. These contact lifecycle operations are controlled through the following directives:

Active contacts handle BP communication through two distinct pathways:

This contact management system enables BPNode to maintain reliable connections with multiple network peers while ensuring data integrity through validation and proper encoding protocols.

When BPNode receives a bundle that cannot be immediately processed—either because its destination EID does not match any active local applications (channels) or available network connections (contacts), the system provides persistent storage to ensure reliable message delivery even across system restarts. Such bundles are written to the SQLite database bplib-storage.db, which provides persistent storage that survives node restarts, ensuring that bundles waiting for delivery or forwarding opportunities are not lost during system maintenance or unexpected shutdowns.

The main task continuously monitors stored bundles to manage their lifecycle effectively. It regularly checks each bundle’s creation timestamp against its specified lifetime to identify expired bundles, which are automatically discarded to prevent indefinite storage of undeliverable messages. Simultaneously, the system monitors for new routing opportunities by checking whether previously unroutable bundles can now be forwarded to newly available contacts or delivered to recently started local applications. When such opportunities arise, bundles are moved from storage to the appropriate egress queue and removed from the database.

The system provides telemetry reporting on storage utilization through the storage telemetry packet, which includes both the total size of the bplib-storage.db file and the actual space consumed by stored bundles. The bundle storage size is typically smaller than the total database file size due to SQLite’s internal database management overhead. Storage capacity is controlled by the BPLIB_MAX_STORED_BUNDLE_BYTES macro, which sets limits based on the actual byte size of bundle content rather than total database file size.

DTNGEN is a Python library that enables the creation and interpretation of DTN bundles for compliance verification as well as error handling and interoperability testing between different DTN implementations. It can create both standards-compliant bundles and deliberately invalid bundles with incorrect data or block ordering.

The tool provides bundle manipulation capabilities through dedicated classes for primary blocks and canonical block types. It can generate:

DTNGEN offers flexible data format support, allowing bundles to be read from and written to both binary and JSON formats:

DTNCLA is a unified Python library that implements CLAs needed for DTN testing. It provides a consistent interface for communicating with DTN nodes, regardless of the underlying convergence layer protocol.

The library follows a modular design where most functionality is shared across different CLAs, promoting code reuse and consistent behavior. Only the network read/write functions are specialized, with implementations tailored to the specific requirements of each convergence layer protocol.

The suite requires the following dependencies:

Each DTN Tools Suite release provides a complete package containing a built Python wheel file (.whl) for easy installation, source code, release notes, and documentation in HTML and PDF formats that covers all classes, variables, and usage examples that can be copied directly into test scripts.

To install for command line usage:

The source code is organized into four main folders:

The DTN Tools Suite seamlessly integrates with OpenC3 COSMOS version 5.12 and later, which supports native Python package installation. DTN Tools packages can be installed directly through the COSMOS Administrator Console, with required dependencies (cbor2 and crccheck) being automatically resolved and installed during the process.

When configuring test environments, any host ports or folders accessed by the DTN test scripts must be explicitly defined in the COSMOS compose.yaml file to ensure proper container communication. The integration enables calling DTN Tools functions directly from COSMOS script-runner, facilitating their incorporation into scripts and procedures.